故事是這樣的

這是幾年前發生在筆者身上的的事情。

有一回我在辦公室裡面讀 Kent Beck 的 Exreme Programming 一書，當時我還不是很了解 Extreme Programmin 在幹嘛。這時，我的同事 Jim 湊過來一看就說了：「這本書我有看過。」

「不錯嘛，那你們當時是怎麼看的？」我來了興趣。

Jim 表示有一回，他前公司的技術大佬拿著這一本書進來辦公室，大佬說他在 一個影片中看到有人在介紹這本書，他覺得不錯，就拿給 Jim 他們看。身為後輩們，收到指令之後一看，原來是英文啊！那就分著看吧。

於是呢，他們就一人分兩三個章節，大家分一分讀一讀，並討論一下心得，就這樣看完了。我就好奇問了：「那你們看完之後有做什麼流程上或是制度上的改變嗎？」

「沒有啊，什麼事都沒變。」Jim 表示，從頭到尾眼睛都沒離開過他螢幕上的 Code（也許是 Bug，我不確定）。

所謂的極限

當時，筆者是在聽過很多年這本書的大名之後，才總算是認真的拿起書來閱讀的。在這之前我一直好奇著（但無法想像），這Extreme Programming 的「Extreme」到底是什麼意思。是把程式寫得超級棒，還是把人力用到超極限，還是什麼呢？直到我打開書本之後看見作者在裡面說了以下的句子：

I asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else.

說老實話，筆者讀的當下也還是有點不太了解。但又過若干年後回想起來，我好像有點想通了。原來極限編程的「極限」，指的是在過去的開發經驗當中，我們（其實是 Kent Beck、Ron Jeffries 一干人等）有一些覺得不錯的好習慣。這些好習慣我們有時候用到這兩個、有時候用到那三個、有時候用到這五個不等，當我們把所有的好習慣集結起來，並且把這些好習慣做到最好，那會發生什麼事情？這是作者 Kent Beck 與 Cynthia Andres 想知道的事。

想到這裡我想通了：啊，原來所謂極限編程啊，就是集結了所有作者們工作中能想到的，關於開發的好習慣的一本讀書筆記兼實踐筆記呀！

為什麼要開到極限？

那麼這些習慣為什麼會被 Kent Beck 與 Cynthia Andres 整理起來，認為是一群值得「開到最大」的好習慣呢？又經過了這幾年之後筆者終於想通了。原來啊，一切還是為了商業價值。

等一下寫程式跟商業價值有什麼關係？

來，我們來一起看看。

Circle of Life，來源：https://ronjeffries.com

上圖是 Ron Jeffries 為 Extreme Programming 統整的圖示，他把這些實踐們分門別類，依照最核心到最外圍整理出來了三個圓圈。並把取名為 Cricle of Life。其中最核心層的是軟體的實踐方式，中間層是開發團隊成員間的協作，而最外層則是開發團隊與客戶間的互動關係。

最外層想當然爾，我們在開發之前，要好好的了解用戶的痛點，才可能提出真正解決用戶問題的 Solution。而在解決的過程當中，最好是這一個團隊靠自己的力量就能所研發出的東西就有能力解決用戶的問題，而不需要在完成一個半成品之後再丟給另外一個 Team 才能解決。這樣一來，用戶才不用花時間在兩個互踢皮球的團隊之間跑來跑去，浪費時間。

什麼？你說你們跨團隊協作完全沒有問題？你當大家第一天出社會嗎？

總之，Extreme Programming 希望我們是 Whole Team。

同時，在解決問題的過程當中，我們其實也無法確定我們做的東西是不是百分之百正確，於是我們一次 Release 一點點、下一次再 Release 一點點，藉此達到一個 Small Release 的效果。此後，我們每踏出一小步，就趕快回頭檢驗一下這步的方向是不是對的。如果是對的，我們就繼續往前走；如果稍微偏差了一點點，我們就趕快調整。最後，如果可以的話，我們邀請用戶來參與我們的驗測過程，或至少監控用戶的使用情形。所以，當客用戶不喜歡，我們就調整；當用戶覺得不好用，我們就調整；當用戶覺得沒有解決他的問題，我們就調整。

最後，當我們直接透過數據看到用戶不喜歡，我們也調整。

第二層講究的是團隊對需求的整體理解，以及產品本身的完整性。因為我們是一個團隊，所以我們的目標並不是把分到自己眼前的工作做完（這是該做的事情，但不是目標）我們的目標是要解決用戶的問題。我們共同擁有這個產品，於是我們做的每一分改動都要讓它立即反映在產品上。為了能做到這件事，我們必須要有一個共同的理解，而且要簡單好理解，因此 Metaphor 也是很重要的。最後，因為我們有了共同的理解，也共同擁有這個產品，於是我們的程式碼與程式碼的撰寫標準是共享的。因為我們想要維持一個長期與客戶的合作關係、我們想要開發一個長期能夠獲利的產品，於是我們不適合衝得太快，也不適合走得太慢，一個 Sustainable Pace，才是健康的開發步調。

最後，在實際上開發時，我們必須得確保所有從我們手上離開的工作，都是在我們能力所及的範圍內驗證過沒有問題的。因此，「測試驅動開發」就成了核心中的核心。在開發的過程中，為了維護我們共同擁有的 Coding Style，並降低人員流動造成的開發阻礙，因此 Pair Programming 也是很重要的。最後的最後，為了能夠維持我們的 Sustainable Pace，不讓開發越走越慢，不讓設計越走越亂，因此在開發過程中，時時刻刻的重構，來讓整座整個程式碼永遠維持在乾淨簡單的設計上，是我們所有開發者都必須共同確保的事情。

講了這麼多，這些事情跟演算法、網路架構、資料結構、IC Design 原理等等的硬技術，根本一點關係都沒有。如前面的文章所述，這些硬技術是你為了開發功能本來就必須得會的東西。 Extreme Programming 的作者們從頭到尾所提倡的都是開發者的「軟」實力，從最外層到中間層到最核心層，一步一步的從基礎開始打好，從自己出發去影響團隊，有了一個紮實而順暢的團隊合作關係之後，再去追求團隊與客戶或是用戶的長期合作關係。

因此我們可以說，Extreme Programming 的十幾項工程實踐，你如果都做得很好的話，那麼你肯定自身的開發習慣、團隊的合作模式、團隊與客戶的合作關係，都能維持在一個很好的狀態。這樣子的開發如果還沒有辦法獲利，那其實就回歸到最一開始的商業模式的問題。這個時候如果要調整商業模式，是不是一件很困難的事，不確定，但在調整的過程當中，我們至少能確保不論是團隊內，或是團隊與外部關係人的合作關係都是健康穩健的。當我們已經把所有可能造成不必要損失的因素都排除掉了，這就是 Extreme Programming 想要達成的目的。

商業為準，工程為本

講了那麼多關於 Extreme Programming 的東西，那麼我不做 Extreme Programming 可不可以？可以，當然可以！說到底，Extreme Programming 只不過是敏捷開發的其中一個框架而已，而敏捷開發也只不過是所有開發模式的其中一種分類而已。退一步來說，假設世界上不存在敏捷開發，那麼你要怎麼確保獲利，或是說，你要怎麼提高獲利的可能性？想當然爾，自然是內耗越少越好，對吧？

所以減少內耗，才是關鍵，是不是 Extreme 什麼的根本也無所謂。

所以，不管你要不要敏捷開發，你都一定要注意兩件事情：1）以商業為準，讓商業來驅動你的開發；2）開發時以工程為本，要有好的強健的工程實力才足夠足以支撐你的商業模式，因它能確保你在開發過程當中除了剛性需求以外的內耗都會被降到最低。假設你能做到這件事情，那是不是敏捷開發也就無所謂了，對吧？

謎之聲：「不要談敏捷，不要跑敏捷，不要導入敏捷，而要變敏捷。」

Reference

1. Kent Beck, Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd Edition (The XP Series), Addison-Wesley, 2004
2. Circle of Life https://ronjeffries.com/xprog/what-is-extreme-programming/circles.jpg